# Lähtekoodi halduse ja ehitamise nõuded !!! info Ühtsed nõuded lähtekoodi haldusele ja ehitusprotsessidele SMIT projektides. Sisaldab versioonihalduse ja ehitusprotsesside standardeid. Suunatud arendajatele, devops inseneridele ja projektijuhteile. ## Versioonihalduse kasutamine ### Git repositooriumid - Tarkvara lähtekoodi halduseks tuleb kasutada [https://source.smit.sise](https://source.smit.sise) Git repositooriumi - Ligipääs antakse projekti põhiselt - Kõik projektid peavad järgima ühtset versioonihalduse mudelit ### Git "workflow" mudelid SMIT projektides kasutatakse ühte kahest põhilisest "workflow" mudelist: #### 1. Git-flow protsess **Kasutada kui:** - Tarkvara versioonide väljastamine on aeglasem ja harvem - Versioonides toimuvad stabiliseerimisperioodid - Vaja mitut erineva funktsionaalsusega versiooni pikaajaliselt toetada **Viited:** - [Git-flow mudel](http://nvie.com/posts/a-successful-git-branching-model/) #### 2. Feature-branch-workflow **Kasutada kui:** - Automatiseeritud paigaldus ja tarneprotsessid - Continuous Delivery või Continuous Deployment töövood - Kiirem väljalasketsükkel **Viited:** - [Feature branch workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow) ## Arendusprotsess ### Feature haru loomine 1. **JIRA piletiga alustamine:** - Iga JIRA pileti realiseerimise alguses - Kasuta JIRA-s käsku "create branch" - Haru luuakse "develop" harust 2. **Nimekonventsioon:** - `feature/XXX-YYY` (kus XXX-YYY on JIRA pileti number) - Järgi konventsiooni järjekindlalt 3. **Arenduse käigus:** - Konfliktide vältimiseks mesti muudatused kesksest harust regulaarselt - Hoia oma haru ajakohane ### Pull Request protsess #### Pull Request loomine 1. Mine versioonihaldus keskkonda: [https://source.smit.sise](https://source.smit.sise) 2. Vali vastava tarkvara ruumi tab **"pull-requests"** 3. Loo uus **pull-request** järgmiste parameetritega: - **Lähteharu:** enda arendusharu - **Lõppharu:** keskne haru - **Ülevaataja:** SMIT poolne kontakt - **Kirjeldus:** täiendavad kommentaarid, mida silmas pidada #### AI koodi ülevaatus Kui meeskond kasutab AI assistenti koodi ülevaatustes: - Tähelepanu automaatsele tagasisidele - Vastus peaks tekkima 30 sekundi jooksul peale pull-requesti loomist  ### Tarne nõuded #### Eeldused tarne üleandmiseks Üleantav kood peab vastama kõikidele kokkulepitud nõuetele või puudused peavad olema selgelt välja toodud pull-requesti kirjelduses. #### Vastuvõtmise kriteeriumid Tarne loetakse vastuvõetuks, kui on täidetud järgmised tingimused: 1. **Bamboo ehitusserver** on edukalt üleantava haru ära ehitanud 2. **SonarQube analüsaator** näitab Quality Gate läbimist 3. **SMITi poolne vastuvõtja** on teinud koodi analüüsi ja heaks kiitnud 4. **Kood on mestitud** ilma konfliktideta "develop" harusse 5. **Kõik commitid** on seotud JIRA piletitega (XXXX-YYY) või sisaldavad selget kommentaari #### Pull-request käsitlus - **Automaatne haru kustutamine:** Kinnitamisel kustutatakse arendaja haru automaatselt - **Tagasilükkamine:** SMIT võib tagasi lükata puuduste korral - **Dialoog:** Võimalik alustada dialoogi koodi ülevaatuse käigus - **AI tugiteenused:** Pull-requesti kirjelduse genereerimine AI abil ## Bamboo (CI/CD) kasutamine ### Ehitusplaanid #### Üldised nõuded - **Iga tarkvaral** on 1 ehitusplaan Bamboos - **Automaatne ehitamine** "develop" või "master/main" haru pealt - **Feature harud** ehitatakse automaatselt, kuid ei paigaldata **Konfiguratsioon:** - [Bamboo haru seadistused](https://docs.atlassian.com/bamboo-specs-docs/9.4.1/specs.html?yaml#plan-branches) #### Ehitusprotsess Bamboo ehitusplaan sisaldab järgmisi etappe: 1. **Koodi ehitamine** 2. **Staatiline analüüs** 3. **Turvaanalüüs** (võimalusel) 4. **Testide käivitamine** 5. **Paigaldus** (ainult määratud harude puhul) ### Git-flow workflow - **Ehitusplaan** liidestatud "develop" haruga - **Automaatne paigaldus** arenduskeskkonda - **Testi ja toodangu versioonid** tekivad "release" harudest - **Käsitsi paigaldus** Bamboo kaudu ### Feature-branch-workflow - **Ehitusplaan** liidestatud "develop" haruga - **Automaatne paigaldus** arenduskeskkonda - **Testi ja toodangu versioonid** tekib master harust ehitades - **Toodangu paigaldus** käsitsi Bamboo kaudu ### Paigaldusprojektid #### Eraldi repositoorium - **Nimekuju:** `xxx-deploy` - **Bamboo spec repo** paigaldusprojekti jaoks - **Keskkonna määratlus:** iga keskkond eraldi Bamboo "env" **Viited:** - [Bamboo keskkonnad](https://docs.atlassian.com/bamboo-specs-docs/9.3.0/specs.html?yaml#environments) #### Linkimine - **Paigaldusprojekt** linkida ehitusprojektiga - **Versiooninfo** liigub automaatselt - **Artifaktid** kanduvad üle vajadusel #### Spec failide haldus - **Sisselugemine:** "master/main" haru pealt - **Bamboo seadistus:** "linked repo" seadistustes - **Versioonihaldus:** spec failid versioonihalduses ## 🛠️ **Praktilised näited** ### Näide 1: Git-flow strateegia Bamboo's **Harude ülevaade:** - **Develop Branch:** Peamine integreerimisharu pidevaks arenduseks - **Feature Branches:** Loodud `develop` harust uute funktsioonide jaoks - **Test Branch:** Pühendatud haru integreeritud testimiseks - **Release Branches:** Loodud `develop` harust, kui valmistatakse ette uut väljalaset - **Main Branch (Master):** Uuendatakse pärast edukat juurutust live-keskkonnas - **Hotfix Branches:** Loodud `main` harust kiireloomuliste probleemide lahendamiseks **Paigaldamise strateegia:** - **Dev Environment:** - Käivita paigaldused automaatselt `develop` harule tehtud muudatuste korral - **Test Environment:** - Automaatne paigaldus: Käivita paigaldused automaatselt `test` harule tehtud muudatuste korral - Manuaalne paigaldus: paigalda release harudest - **Prelive Environment:** - Manuaalne paigaldus `release` harudest (nt `release/x.y.z`) - **Live Environment:** - Manuaalne paigaldus `release` harudest - Nõuab manuaalset kinnitust enne juurutamist live-keskkonda - Pärast edukat paigaldust merge `release` haru `main` haruga **Main Branch'i roll:** - `Main` haru uuendatakse pärast seda, kui `release` haru on edukalt juurutatud live-keskkonda - Hotfixid luuakse `main` harust ja mergetakse tagasi nii `main` kui ka `develop` harusse pärast testimist ### Näide 2: Feature-Based Workflow strateegia Bamboo's **Harude ülevaade:** - **Develop Branch:** Peamine integreerimisharu pidevaks arenduseks. Kõik funktsioonid merge'takse siia - **Feature Branches:** Loodud `develop` harust uute funktsioonide jaoks. Pärast valmimist merge'takse tagasi `develop` harusse - **Main Branch (Master):** Uuendatakse pärast `develop` haru testimist ja kinnitamist. Kasutatakse testimiseks ja tootmisse viimiseks - **Hotfix Branches:** Loodud `main` harust kiireloomuliste probleemide lahendamiseks **Paigaldamise strateegia:** - **Dev Environment:** - Käivita paigaldused automaatselt `develop` harule tehtud muudatuste korral - Kõik funktsioonid testitakse esmalt arenduskeskkonnas - **Test Environment:** - Automaatne paigaldus: Käivita paigaldused automaatselt `master` harule tehtud muudatuste korral - `Develop` haru merge'takse `master` harusse, kui kõik funktsioonid on valmis ja testitud - **Live Environment:** - Manuaalne paigaldus samast pakist, mis läks testkeskkonda - Nõuab manuaalset kinnitust enne juurutamist live-keskkonda - Pärast edukat paigaldust jääb `master` haru tootmiskoodiks **Töövoo tagajärjed:** See töövoog tagab, et kõik funktsioonid läbivad esmalt arenduskeskkonna testimise, seejärel integreeritakse need `master` harusse, mis läbib testkeskkonna, ja lõpuks viiakse sama testitud pakk manuaalselt tootmiskeskkonda. ## Seotud dokumendid - [Git Workflow juhendid](ci-cd-pipeline-standardization.md) - [CI/CD Pipeline standardid](ci-cd-pipeline-standardization.md) - [Koodi ülevaatuse juhendid](code-review-guidelines.md) - [SonarQube nõuded](../04-development-tools/sonarqube-requirements.md) ## Märkused - Kõik nõuded on kohustuslikud SMIT projektidele - Dokumentatsioon ajakohastatakse regulaarselt - Erandid vajavad arhitektuurinõukogu heakskiitu --- > **📝 Git-managed page:** This content is automatically synced from [IDP Documentation Repository](https://source.smit.sise/projects/IDP/repos/idp-docs/browse/docs/02-development-guidelines/version-control-standards.md). **Do not edit manually in Confluence** - all changes should be made in Git and will be automatically deployed.